IMO rather than adding this as a shell integration option, instead look for some shell global variable in the integration scripts and if it is set send click_events with the prompt marking. Then the user only has to configure click support in one place, his rc files, to load the click support code. That code in turn should set the shell global variable and the shell integration scripts should read the variable.

The approach I took was based on this comment. My reading of that was that zsh themes / rc files should append to $KITTY_SHELL_INTEGRATION to change behavior; is that not what it means? Would you rather I use a separate environment variable regardless?

This is not a shell integration feature so much as a shell capability.
If the shell supports handling of click events, shell integration should
enable it automatically, if not it should fallback to fake arrow key
events. So currently zsh does not support this functionality natively but
it can be patched to do so via zshrc, but in the future zsh may gain
this functionality natively. The shell integration script should thus
just check if zsh has been patched to support click events and if so
enable that functionality. In the future if zsh gains this natively,
theintegration script can check the zsh version and turn on the
functionality based on that.

I understand your reasoning, but I'm not sure what mechanism you're proposing. Checking zsh version for the future where zsh supports this natively is one thing. For the in-between times, though, where folks would need to use something like https://github.com/stephane-chazelas/misc-scripts/blob/master/mouse.zsh , how should the shell integration script be told that this patching has been done? Should there be a separate environment variable like $KITTY_SHELL_INTEGRATION_SEND_MOUSE_EVENTS that the shell integration script listens to?

User cources that script and sets a non exported env var or zsh global.
The shell integration script checks for that, and turn on clicks if it
is present.